Business entities require business software for performing an array of essential tasks, such as communication, planning, inventory control, order processing, systems monitoring, and nearly every facet of a business' operations. A business entity often requires a software solution with features, interfaces, data management, and other aspects unique to that one specific company. Yet, core functions may be similar among the different unique solutions. These core functions may be provided to several, unique business entities, e.g., companies. In addition to needing to vary several initial deployments among a variety of customer-companies, these varied implementations may need constant updating, to evolve with the evolving business' needs.
Software developers may design and provide a set of software tools in a generic or universal form. These tools may provide a functional foundation for a software suite (e.g., a plurality of related applications). The software suite may provide various interfaces to released objects (e.g., public objects) so that end-user clients may customize various aspects of their specific install of the software suite. With customer configuration data, customers may be able to modify every aspect of their software experience, including defining the user interfaces, what functions are available on the interfaces, and/or what fields are provided to the user.
To help maintain these software packages, SAP AG (a developer) introduced an enhancement package strategy as a means to simplify the way customers manage and deploy new software functionality. Customers may selectively implement these software innovations from a developer and activate the software upon business demand. As a result, customers can isolate the impact of software updates from introducing/rolling out new functionality and bring new functionality online faster through shortened testing cycles. Customers no longer have to plan for major releases every few years. They may now choose to selectively implement the business functions or technical improvements that add the value that matters most to their business. A developer may use enhancement packages to quickly and easily deliver business and industry-specific functionality, enterprise services, and other functions that help improve and simplify the use of software through user interface and other end-to-end process improvements.
These enhancement packages may have some inflexible characteristics. For example, the enhancement packages may be cumulative from a functional perspective, e.g., current enhancement packages may contain the entire content of earlier packages. So each enhancement package may be based on the previous one. Enhancement packages may also have the same maintenance duration as the underlying core application. Each enhancement package may contain new versions of existing software components. With the enhancement packages customers can choose which software components are updated in their systems, depending on the new/extended functionality they want to use, but the entirety of the software package may be delivered as a whole, regardless of which parts are new and which parts are activated after delivery.
A software suite utilizing the enhancement package update strategy (e.g., ERP “Enterprise Resource Planning”) may comprise several relatively decoupled software components. The software components may comprise the units that can be installed separately by customers (e.g., through the switch framework and enhancement package deliveries). This may mean that customers interested in innovations from Human Resources might only install the software components related to that area, e.g., EA-HR and/or SAP_HR, whereas customers interested in innovation from the retail business might just install the software components related to retail, such as EA-RETAIL and SAP_APPL, in addition to any underlying foundational components.
The EHPs (e.g., enhancement packages) may be delivered approximately every 12-18 months and an EHP may contain a new version (containing innovations) of each software component. Each software component may mean a new version of the source code which may need to be maintained until a contractually agreed maintenance period ends. This may mean each new source code version creates additional maintenance effort for the developer. This also means that it is in the interest of the developer to have as few as possible different source code versions. On the other hand, there is also a competing interest in offering new innovations as fast as possible to market, so that the customers can use the new functionality as soon as possible. Further, each investment area (e.g., human resource, financial, or retail) may act like independent development projects with their own customer segments, own innovation ideas, and the groups may desire to supply their respective market segment in timeframes they believe are best for their respective solutions.
Current EHP solutions may not facilitate this individuality, as an EHP may have a common timeline, where each investment area has to release within the same 12-18 month interval. Thus, it may be that areas being ready for delivery have to wait for the common EHP shipment date and areas not ready for delivery at the EHP shipment date have ship what they have and do the rest in the next EHP. For internal projects this creates an inefficient compromise, leading to delayed market entry for faster components and leading to additional source code version for the ones which have huge and long running investments (e.g., those that needed more time and thus has a partial release followed by finishing releases in the next cycle).
Example embodiments of the present invention may provide a more tailored delivery of EHP components.